Signed-off-by: srlch <[email protected]>
(cherry picked from commit 96b97a7)

# Conflicts:
#	fe/fe-core/src/main/java/com/starrocks/sql/analyzer/QueryAnalyzer.java

…Rocks#50398)

Signed-off-by: srlch <[email protected]>

…Rocks#50398)

Signed-off-by: srlch <[email protected]>

…Rocks#50398)

Signed-off-by: srlch <[email protected]>

…port StarRocks#50398)

Signed-off-by: srlch <[email protected]>

…port #50398) (#50830)

Signed-off-by: srlch <[email protected]>

…port #50398) (#50831)

Signed-off-by: srlch <[email protected]>

…Rocks#50398)

Signed-off-by: srlch <[email protected]>

Why I'm doing:
This problem is introduce by pr #StarRocks#50398. When we re-analyze the generated expression
in current scope for subquery, sometime we may meet an exception. In current implementation,
a map will be clear but the iteration does not break cause ConcurrentModificationException.

What I'm doing:
Remove the expression if re-analyze throw an exception instead of clear all generated column
expression.

Signed-off-by: srlch <[email protected]>

…relation if left table and right table has the same column name

Why I'm doing:
This problem is introduced by pr StarRocks#50398. In this pr, we introduce some new rule for generated column rewriting.
The basic idea is following:
1. Collect the rewriting relation in every SELECT scope in query. (Expr -> ColumnRef)
2. Translate the expression relation into Operator mapping: ScalarOperator -> ColumnRefOperator
3. Introduce new rule says ReplaceScalarOperatorRule, use this new rule to replace the ScalarOperator
   into ColumnRefOperator when generating the logical plan in optimizer.

This problem is that, ReplaceScalarOperatorRule use ScalarOperator.isEquivalent to check if a ScalarOperator
is hit the rule instead of using ScalarOperator.equals. ScalarOperator.isEquivalent does not check the operator
id but this id will be used to indentify the column with the same column name but come from different table in JOIN
relation. (e.g column xx in TABLE A and column xx in TABLE B has same name but different id, in this case, ScalarOperator.isEquivalent
return true but ScalarOperator.equals return false). So in this case, we will get the wrong mapping and generated a
incorrent plan for generated column rewrite.

What I'm doing:
1. Using ScalarOperator.equals instead
2. Introduce session variables disable_generated_column_rewrite for disable the generated column rewrite if we want.

Signed-off-by: srlch <[email protected]>

…relation if left table and right table has the same column name

Why I'm doing:
This problem is introduced by pr StarRocks#50398. In this pr, we introduce some new rule for generated column rewriting.
The basic idea is following:
1. Collect the rewriting relation in every SELECT scope in query. (Expr -> ColumnRef)
2. Translate the expression relation into Operator mapping: ScalarOperator -> ColumnRefOperator
3. Introduce new rule says ReplaceScalarOperatorRule, use this new rule to replace the ScalarOperator
   into ColumnRefOperator when generating the logical plan in optimizer.

This problem is that, ReplaceScalarOperatorRule use ScalarOperator.isEquivalent to check if a ScalarOperator
is hit the rule instead of using ScalarOperator.equals. ScalarOperator.isEquivalent does not check the operator
id but this id will be used to indentify the column with the same column name but come from different table in JOIN
relation. (e.g column xx in TABLE A and column xx in TABLE B has same name but different id, in this case, ScalarOperator.isEquivalent
return true but ScalarOperator.equals return false). So in this case, we will get the wrong mapping and generated a
incorrent plan for generated column rewrite.

What I'm doing:
1. Using ScalarOperator.equals instead
2. Introduce session variables disable_generated_column_rewrite for disable the generated column rewrite if we want.

Signed-off-by: srlch <[email protected]>

…Rocks#50398)

Signed-off-by: srlch <[email protected]>
Signed-off-by: zhiminr.ren <[email protected]>